1. The Field of the Invention
This invention relates to systems, methods, and computer program products for generating computer program code for use with localized resources on a client computer.
2. Background and Relevant Art
Computerized, electronic systems are increasingly common, in part because such computerized systems automate much of what people previously had to perform manually. Accordingly, computerized systems have added a certain amount of efficiency to people's ability to perform tasks. In general, computerized systems may comprise a wide variety of devices such as desktop or laptop computers, personal digital assistants, wireless and corded telephones, televisions, software applications, and even such seemingly mundane devices as toasters, and refrigerators. Computerized systems can be part of a platform and can run (or can be made to run) an operating system. Thus, for a computerized system such as a personal computer or wireless telephone to perform a requested function, the computerized system must be able to read and execute operating system (OS) or platform specific executable instructions that cause the computerized system to perform the function.
The process of generating executable instructions for a computerized system is somewhat involved. Ordinarily, a software developer must first think of the desired functions or results that the executable instructions are to perform and then enter corresponding text-format instructions, typically in the form of programming source code, into an electronic text file. In some cases, such as with interpreted programming languages (e.g., Javascript, Perl, etc.), a computerized system directly interprets entered text-format instructions, and performs the desired function. In other cases, such as with compiled programming languages (e.g., C#—pronounced “C sharp”, C++, etc.), text-format instructions are first compiled into object or machine codes that the computerized system can execute. The computerized system can then execute the compiled object or machine codes to perform desired functions. Thus, executable instructions can be text-format instructions that are “interpreted” or can be compiled object or machine codes that are run.
After a software developer creates executable instructions (whether that be text-format or compiled instructions), a device manufacturer or end user must then enter or load the executable instructions into a computerized system for the instructions to be useful. This may be done by running an executable install file from a CDROM, downloading the executable instructions from a local or wide area network file server (e.g., Internet website), wireless uplink, etc. In short, there are a variety of ways to load executable instructions into a computerized system so that the computerized system can execute the executable instructions. Regardless of the loading procedure, however, for loaded executable instructions to be useful, a computerized system must be able to read the loaded executable instructions (hereinafter referred to as a “software program”).
Computerized systems, however, can be less efficient for a desired function or may not even be able to perform a desired function when a software program that is to perform a desired function does not operate as intended. Failure to operate as intended can result from inadequacies in the software development process and/or software program malfunctions (often referred to as “bugs”) when a software program is executed. Some software program malfunctions can have a significant detrimental effect on the operation of a computerized system, causing a complete inability of the executed software program, and potentially other software programs, to appropriately run on the computerized system.
Other software program malfunctions may be as mundane as the executed software program failing to output a correct word. For example, a software developer may misspell words or phrases in text-format instructions that are necessary to perform a function when the software program is executed. Sometimes these types of software malfunctions can be obvious to the programmer (e.g., every function but the misspelled function works), or can be unobvious (e.g., a video display goes blank and a generic “exception” message appears on the screen). Software malfunctions in a software program, especially those that are difficult to detect, can disrupt the intended functionality of the software program. More mundane software program malfunctions can also reduce a software developer's efficiency in writing text-format instructions as the software developer must often spend time trying to identify unobvious errors in text-format instructions.
Not surprisingly, there are a variety of automated ways that software developers develop and compile software so that the software developers can identify errors before they install, use, or sell the software program. As previously mentioned, a software developer may use a compiler to compile text-format instructions into object or machine codes that can be executed by a computerized system. Many compilers check text-format instructions for errors, and allow the software developer to “debug” errant text-format instructions. Such compilers, however, ordinarily look for illogical program code sequences (a missing bracket, missing if/then congruity, etc.).
In addition, there are of course non-automated (i.e., human) ways of checking text-format instructions for errors. For example, it is fairly common for teams of software developers to write code for a software program (or group of interrelated software programs). Utilizing a team of software developers has the added benefit of allowing several people familiar with or expert on the software product to check each other's code for errors. Utilizing a team of software developers, however, also has the added detriment of a greater potential for human errors, such as spelling errors. In addition, human error checking is often less desirable since software developers on very large projects may have limited time to review another's work. Thus, similar to automatic error detection mechanisms (e.g., in a compiler), software developers may be more inclined to look for overall program logic errors, and thus disinclined to review a text-format instructions with the specificity necessary to pick more mundane errors, such as, for example, spelling errors. Consequently, software programs having more code and greater numbers of software developers have the potential for greater numbers of such mundane errors that can cause a software program to fail, or deviate from the intended functionality.
As an example in some platforms, a software developer may write a software program that passes in localized resources, such as “string” resources (e.g. welcome_string=“Hello ‘{name-id}’, welcome to the program”) and other related resource parameters, from a separate resource file that exists on the computerized system executing the software program. The resource file may include a number of resource identifiers such as string identifiers (e.g., name-id, language-id, or OS-id, etc.), and a series of corresponding resource (or string) values (e.g., “John”, “Spanish”, or “WinXP”) that are used to represent different resources. For example, a resource file could contain the following resource identifiers and corresponding resource values written in text-format:                Welcome_String=Welcome        Earnings={0} earned ${1} last yearThese sorts of resource identifiers (i.e., Welcome_String, Earnings) and corresponding resource values represent resources that can allow a software program to be platform, or end-user-specific for a wide variety of parameters, even after the program is compiled. Treating resources separately from the main code in this manner facilitates a number of functions, such as translating (or “localizing”) the string resources into different languages.        
In some development environments, to cause a software program to access a certain resource such as a string value from a resource file, the software developer must enter another sequence of text-format instructions, or a “routine”, that accesses the resource file for the corresponding certain resource identifier (e.g., string identifier). Accessing the resource file may occur prior to or after compiling the routine. In at least one case, the software developer enters text-format instructions enclosing a string identifier in quotation marks so that the compiler will not try to interpret the string identifier as a function or variable. Thus, a software developer might write, for example, get(“Welcome_String”), rather than get(Welcome_String), where “get” is a function and “Welcome_String” is a string identifier that references a string value (i.e., “Welcome”).
Software developers in such a development environment may also be required to write out a separate function each time the software developer wishes to pass this or a similar string resource from the resource file into the routine that will eventually be compiled. For example, a software developer might write text-format instructions to reference the named string identifiers from the previous resource file as follows:    ResourceManager resources=new    System.Resources.ResourceManager(“ClientStrings”,    this.GetType().Module.Assembly);    Console.WriteLine(resources.GetString(“Welcome_String”));    String s=resources.GetString(“Earnings”);    s=String.Format (s, “John Doe”, 5000);    Console.WriteLine(s);Writing text-format instructions that access resources in a manner similar to the above example text format instructions is problematic for at least a few reasons. One reason is that using quotation marks around the string identifiers (i.e., “Welcome_String”, and “Earnings”) typically prevents compilers from checking for spelling errors in the string identifiers at compile time, making them harder to detect. Thus, the resulting software program may generate an “exception” at run-time (i.e., during an end-user's execution of the software program), as opposed to being identified by a developer during development of the software program.
For example, if the software developer enters the text-format instruction get (“Wel9comee_String”) and the resource file instead contains a string identifier “Welcome_String”, a compiler may not identify an error in this text-format instruction if other text-format instructions (e.g., a “get” command) that access the corresponding string resource are properly invoked. That is, the compiler will check the logic of the text-format instructions but typically will not check what is contained within quotes. A software program malfunction resulting from the spelling error may only become apparent when the software program containing the text-format instruction is executed by an end-user. For example, a software program could malfunction when trying to output a string from the resource file that corresponds to the “Welcome_String” identifier (i.e., “Welcome_String” exists in the resource file, but “Wel9comee_String” does not). In most cases, this will show up as a run-time “exception” that will be difficult for either the end-user or software developer to decipher (e.g., “exception error 10×01001—missing identifier”) and/or correct.
To catch errors such as these, a software developer would ordinarily have to run all the code (before shipping the software program) that loads every string to make sure each string works properly. Presumably, normal software developer testing in this manner could identify many string errors (some strings, however, may be loaded in obscure error conditions). Unfortunately, in part due to the large number of text-format instructions in many end-user software programs, it is generally fairly easy for a developer to introduce an error late in the development process without realizing it.
Accordingly, systems, methods, and computer program products that aid software developers in developing software programs that have fewer errors and that reduce the lines of code a software developer enters to develop a software program would be advantageous. More particularly, systems, methods, and computer program products that reduce the potential for bugs to be entered into a computer readable program would also be advantageous.